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SUMMARY '•■-.' 

I am pleased to present the report documenting our evaluation of XOS 
and XMS. This report is essentially the same in format and content as 
the flip chart presentation v;e prepared for the management meeting on 
October 21. ■ 

We did not draw any conclusions or make any recommendations relative to 
the XOS - XMS alternatives. We have, -however, several related recommenda- 
tions which are a direct result of this study. 

RECOMMENDED ACTION " ' 

1. A project should be initiated to create brochures marketing the 
existing communications capabilities of UTS for business information 
systems. 

2. A project should be initiated to recommend enhancements to UTS 
required for business information systems. 

3. The functional similarity of XDS keyed random file management to 
IBM's ISAM should be exploited from a marketing point of view, and 
inherent advantages should be stressed. 

4. A project should be initiated to identify enhancements to XDS keyed 
random files to improve performance during sequential processing of 
disk-resident files. 

BACKGROUND 

1. UTS communications capabilities can be applied very effectively to 
implementing network or dedicated information systems. UTS functions 
are different from BTAM and QTAM, thereby creating the impression that 
UTS communications services are not adequate for these applications. 

2. UTS provides only a small part of the services required for business 
information systems. Extending UTS communications functions, 'would 
strengthen the multi-use capabilities of UTS. IBM's TCAM should be 
evaluated as a possible guideline for UTS extensions. 
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3. There is a great deal of functional similarity between ISAM and XDS keyed 
random file access method. Marketing should exploit this capability and 
stress inherent advantages where they exist. 

4. The XDS keyed random files are "randomly" distributed on disk files, 
resulting in excessive disk arm movement during sequential processing 
(frequent in BDP environments) . 
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INTRODUCTION 

Background 

A memorandum from W. F. Glavin on October 8 requested that the pros and cons 
of XOS and XMS be evaluated prior to any decisions being made to proceed with 
either or both programming systems. This report is the result of the Marketing 
Division's study conducted by Norm Bryga, Jim Hargrave, Ed Keh, Bob Kemp and 
Line Miller. 

Marketing Objectives 

The evaluation of any operating system requires an Appreciation of the corpora- 
tion's marketing objectives. For the purposes of this study, we accepted the 
Marketing Division's proposed strategy, which is: 

(a) Maintain and strengthen our traditional real-time and scientific 
position 

(b) Pursue extensions to our traditional markets via multi-use applications 
where real-time, time-sharing and/or scientific processing is important. 

(c) Establish a growth base in the BDP and on-line, transaction oriented 
marketplace. 

Evaluation Method 

The objective of the study team was to collect available facts necessary to 
support Management's XOS-XMS decision. We avoided attempts to draw conclusions, 
make recommendation, or to bias the information by applying judgment or confidence 
factors. These, we felt, were part of Management's decision making process. 

We identified seven areas which required evaluation. These are: (1) availability, 
(2) performance, (3) functional characteristics, (4) hardware considerations, 
(5) expandability, (6) conversion, and (7) logistics (supportability) . In 
addition to the knowledge of XOS and XMS possessed collectively by the study 
committee, we proceeded to: 

(1) meet with the XOS proponents, 

(2) meet with the XMS proponents, 

(3) evaluate and consolidate our information unto flip charts, 



wi;'!i nil i { ni Vril L 



\j\JVHi A-UM ii I US Vrii L 



5. EXPANDABILITY 



Time- Sharing 



Communications Management 

'.'I 

Sigma 9 Extended Memory 
Sigma 9 Multi-Processor 



XOS 



A- 2 

XMS 
Exists (UTS) 



Difficult (Esti- 
mated 9 man-years 
minimum, may be 
implemented by CII) 

Difficulty is unknown, but is estimated 
to be equally difficult under XOS and XMS 



XDS effort 

Easier, since 
we could utilize 
SIRUS 8 concepts 



Easier, use UTS 

extensions 

More difficult, but 

would utilize UTS 

extensions 



6. CONVERSION 



XOS 



Easier to convert IBM user to XOS 



XMS 



Easier to convert XDS user to XMS 



7- LOGISTICS (SUPPORTABILITY) 
XOS 
More difficult and expensive because 
of outside vendor dependency, trans- 
lation, merging XDS and CII updates, 
separate libraries, etc., in 
addition to that required for 
UTS. 



XMS 
Would be an extension to UTS, there- 
fore would not require a major 
additional support and training 
effort. 









A-3 



(4) present our information to a Marketing Division staff 
meeting attended by Bill .Glavin and George Boyd, 

(5) present our information to a joint meeting of the XOS and 
XMS proponents to calibrate and correct our information, 

(6) present part of our information to Don Shaw, Frank Yee 
and Errol Forkner to test our understanding, 

(7) present our information to a management committee considering 
the XOS -XMS alternatives. 

We believe the above procedure has allowed us to meet our objective of 
presenting highly reliable information. 

Information Sources . ... 

In the process of collecting information; we interviewed: 

George Boyd (Software Product Planning Manager) 

Ed Bryan (Programming Development - UTS Manager) 

Dan Cota (Programming Development Director) 

Buddy Doeppel (Programming Development - UTS, XMS Designer) 

Fred Haney (Programming Development - XMS Manager) 

Doug Heying (Programming Development - BTM, F00 File Management) 

Max Mueller (Program Management - XOS) 

Bob Sharp e (Programming Development - XMS, IBM OS Spec) 

Wendell Shultz (Program Management - Technology Manager) 

John Weaver (Software Product Planning) 

The following were the major documents used in the study: 

All the published translated XOS (MMP) documents 

Most relevant XOS memos and correspondence 

Interim Final Report on MMP Evaluation 

Memorandum, Wendell Shultz, September 29 on MMP Evaluation 

XMS - A00 Functional Specifications 

Conformance Report, XMS-AOO, Review Board, September 16 
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SUMMARY OF ANALYSIS 



The following is a summary of the analysis performed on XOS and XMS . The 
details supporting the statements in this section are included as Section B 
to this report. 
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AVAILABILITY (First Release) 

XOS 

Objective date - August 1971 

(Initial Release to include 
multiprogramming; Telecommunica- 
tions Access. Method; disk residence; 
some XDS program products; no time- 
sharing; no checkpoint-restart; 
no real-time) 

Risks-' 

- XDS 1 success is highly dependent 
upon CII dedication 

- MMP- 2 may continue to be unstable 

- Translation is a very large 
problem 

- Learning XOS code may be difficult 

- Size of delay between CII release 
and XDS release is unknown 

- Work plan non-existant 



XMS 

Objective date - August 1971 

(Initial Release to include multi- 
programming; UTS communications 
services; all XDS program products; 
time-sharing; basic checkpoint-restart; 
no disk residence; no real-time) 

Risks- 

- XMS is planned as an extension of UTS. 
The UTS architecture may be a con- 
straint in achieving the XMS objectives, 

- UTS may continue to be unstable 

- Complexity of integrating XMS, F00 FM, 
and UTS is unknown 

- Work plan exists, but past conformance 
record is poor 



2. PERFORMANCE 

Insufficient data is available to properly evaluate the performance of XOS 
and XMS. It was generally agreed that: 

(a) XOS is designed to optimize the turnaround of the highest priority jobs, 
at the expense of resource utilization (total throughput) ; 

(b) XMS. is designed to optimize the resource utilization of the system 
(total throughput) , at the expense of the turnaround of the highest 
priority jobs; . 



fT^-DAHV r-nr</:vrr 



pn^DAWV PP1VATF 



A-5 



(c) We should not expect throughput to vary by more than 10%; and 

(d) Benchmarks could be devised to show either XOS or XMS to be faster 



3. FUNCTIONAL CHARACTERISTICS (Initial Release) 

XOS 
Multi-batch Facilities Good 

File 'Management Better than XMS, 

,/ i probably faster 

ad(NS' ■ ~^"~" -■ 

Communications ^ ^ \£ it-ai^ ./<ri 77?Af Yes (IBM-like 

approach) 

J^oo ltd- -~i^' r 
_ LVJOJL 

Time-Sharing (JbTBMj ^A cm pi ^J Ho (planned) 
Real-Time No (planned by 

CII) 
Symbionts Functionally 

equivalent 
System. Management 
Checkpoint-Restart , ""tpianned for 

later releas^e)- 



XMS 
Better Features 
Functionally Equivalent 
to XOS 

Yes (UTS services different 
than IBM's and does not 
support polled terminals 
now) 

Yes (UTS) n , . /w.N 
wci (Depends on Marketing's 
priorities) 
More convenient to use 

More flexible ~-^^/ A ^ c 
Basic functions available 



4. HARDWARE REQUIREMENTS 



Core Residence 



7 240/ Support 



System Residence 



XOS 
14K (min) to 22K 
(Typical) ThM f ' 



Require. XDS effort 



/ 



y 



to^support under 
~x6s 
RAD or Disk 



XMS 



2_2- 



About 6K larger (K>K 
to 28K) than XOS (no 
time- sharing) 



RAD (Disk planned) 
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CLOSING REMARKS 



XOS -In selecting XOS, it must give us a clear advantage in some of the , p 

following areas: ft nMv**\ 

- Availability (for benchmarking, demonstration, and installation) 

- Performance (particularly in multi-programmed batch) ■ - ~> > (Zfn'^' 4t ^ 

- Functional capabilities t^>^^ d*&uJhdsK~ feuz tC o 

- Market coverage (batch and transaction processing) ~~M& 

- Expandability to Sigma 9 (extended memory, multi-processor) ^° 

- Salability (IBM - like services) , 

to justify the cost of: 

- Purchase price * - 

- Logistics, (translation of documentation, publication, modification) 

- Support, (education, duplicate libraries, etc.) 

- Product Line Discontinuity 

XMS - However, if we select XMS, will it meet: 

- Functional Specifications, and 

- Delivery Schedule (August, 1971), and 

- Batch Performance (throughput)? 
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ALTERNATIVES 

We have identified three reasonable alternatives available to XDS: 

(a) Buy XOS, terminate the XMS development effort, and apply those 
resources to the large logistic problem associated with XOS. 

(b) Develop XMS and use XOS resources to reinforce XMS development 
to assure .delivery. 

(c) Continue the development of XMS as planned and re-negotiate with 
CII to allow XDS to evaluate and monitor both XOS and XMS during 
1Q71, then reconsider the XOS -XMS choice again. This would be the 
most expensive alternative. Considering the unknowns of XOS and 
XMS, this alternative reduces the risks associated with alternatives 
(a) and (b) . 
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SECTION B 



DETAILED ANALYSIS 

This section described in further detail the analysis of 
XOS and XMS under the following headings: 

1. Availability B- 2 

2. Performance . . .'. B- 7 

3. Functional Characteristics ... . ... B- 8 

4. Hardware Considerations B-19 

5. Expandability B-20 

6. Conversion . . . . . B-22 

7. Logistics B-23 
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1. AVAILABILITY 



Both XOS and XMS are planned for release to XDS users in August, 1971, 
XOS represents a sizable translation and logistics problem. No work 
plan exists, which leads to the premise that this task is not very 
well understood. On the other hand, a work plan for XMS does exist, 
supported by detailed Functional and Implementation Specifications. 
One is reminded, however, that the Programming Division has grossly 
misjudged task sizes, complexities and schedules in the past. 

It is apparent that both XOS and XMS schedules are speculative to 
a very large extent. The following charts are presented to allow a 
more rational analysis of stated schedules. Tnese charts represent 
the amount of code involved, the size of the tasks involved, and the 
time scale in which these tasks are to be performed. 

The identified risks are listed in the Summary of Analysis (Section A 
of this report) . 






AVAILABI LITY (Continued) 

This chart represents the tiers of code upon which XOS and XMS are 
built. The first tier (lowest) represents the size of existing code 
and its maturity. The second tier represents the amount of code in the 
process of creation. The third tier represents the work to be done prior* 
to release in August, 1971. 

XOS - XMS 



XDS XOS 

XDS Receive 1/71 

Translate 

2K Lines Code 

Rel — 8/71 



MMP-4B 
20K Lines 

MMP-4A--Q.A." 10/70 
MMP-4B— Q.A.&BETA-1/71(*) 



MMP-2 125K Lines 

Q.A. & BETA - 6/70(*) 







XMS 

20K Lines 
"Code & Integrate 
Q.A. —4/71 
Rel— 8/71 








UTS 

40K Lines 
Q.A. —4/70 
Rel— 1/71' 


FOO-File Mgmt 
14K. Linesv, ■<£■ 
Q.A.' — 9/70 
Rel — 1/71 


— 


BPM-E00 130K Lines 
in field 



Multi-programming; Telecommunica- 
tions Access Method; some XDS 
program products; disk residence; no 
time- sharing; no checkpoint- 
restart; no real-time. 



Multi-programming; UTS 
communications; time-sharing; all 
XDS program products; basic check- 
point-restart; no disk residence; no 
real-time. 



*It is. noted that CII release MMP to Beta test sites at the same time 
as to Q.A. Similarly, this could also be done for batch only XOS and XMS 









B-4 



AVAILABILITY (Continued) ■' _ . 

This chart represents a further breakdown of the work in process and 
work to be performed. This chart identifies the number of lines of 
code since these approximately represent the size of the task to be 
performed. 



xos 



XMS 



CODE 

INTEGRATE 

TEST 

Q.A. (CII) + BETA 

TRANSLATE 

LEARN 

CODE 7240, ETC. 

INTEGRATE PROCESSORS 

XDS Q.A. 



20K 

20K 

MMP2. + 2 OK 

MMP2 ■+ 20K 

MMP2 + 20K 

MMP2 +'.20K 

2K 

1 

MMP2 + 22K 





20K 




to 


34K 


to 


•1/71 


UTS + 34K 


-4/71 


(CII) 


N/A 

N/r 

N/A 


(XDS) 


1/71 


N/A 


-4/71 


to 


9 


to 


8/71 




8/71 


(XDS) 


UTS + 34K 


(XDS) 
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AVAILABILITY (Continued) 



The following two charts identify the tasks to be performed between 
now and release on 8/71. In the case of XOS, no work schedule exists. 
The tasks are therefore grouped together and represented by a broken 
line with no specific start date. 



XOS 



MMP-4A TURNOVER TO XDS 



MMP-4B TURNOVER TO XDS 



LEARN MMP 



TRANSLATE MANUALS 



TRANSLATE DESIGN DOC. 



TRANSLATE LISTING COMMENTS 



TRANSLATE MNEMONICS (?) 



CODE 7240 MODS, ETC. 



PROCESSOR INTEGRATION 



XDS Q.A. 



CONTINUAL UPDATES 



— > 



70 
10 11 12 



71 

12345 6 78 9 



-x x x x — x — x — x — x — x — x~ 



-X_ 



10 11 12 
70 



JX X XX X v v X v 



123456789 
71 
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AVAILABILITY (Continued) 



XMS 



XMS CODE 



FILE MGMT-FOO INTEGRATION 



UTS-AOl INTEGRATION 



PROCESSOR INTEGRATION 



TOTAL INTEGRATION 



FUNCTIONAL TESTS (Q.A..) 



SYSTEM 'TESTS (Q.A.) 





70 










71 










10 


11 


12 


1 


2 


3 


4 5 


6 


7 


8 


9 


X 
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a 


a. 
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X 


X a 
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t- 


.A. 



x- 



•x 



•x 



X — X 



X 
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X 
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X X 


X 
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X 


X 


10 


11 

70 


12 
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2. PERFO FIANCE 

Every batch-oriented sales situation is highly competitive, and most 
involve some degree of benchmarking. .The committee spent a large 
amount of time trying to determine which Operating System offered 
the greatest throughput advantage. 

Available benchmark data could not be used because of accounting differences, 
and because the XOS benchmarks had not been run under UTS or BPM. Further- 
more it is possible to benchmark UTS or BPM only in mono-programming mode. 
We could not assume, however, that multi-programming performance would be 

directly proportional to mono -programmed throughput. 

I 

In the absence of empirical data, an attempt was made at a deductive analysis 

of the systems' architecture. . . 

XOS is designed to optimize the turnaround of the highest priority class, 

even though some available system resources may not be utilized. The 

performance capability of XOS File Management is considered to be better 

than XMS.. 

i 

On the other hand, XMS is designed to optimize total throughput by optimizing 
the utilization of system resources. In accomplishing this, the turnaround " 
of . the highest priority class would be reduced. 

It was generally agreed that we should not expect a performance difference 
greater than 10%. A difference of only 10% was not considered significant, 
and may be highly sensitive to the make-up of the benchmark. 
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3. FUNCTIONAL C1IARACTERISITCS 



■"• Multi-Programming 



XOS 

( a ) Job Scheduling 

There are three job classes: 
parallel (highest priority), 
production (five sub-classes) 
and serial. . 

Jobs in the parallel class are 
scheduled FIFO (until job queue 
or class resources exhausted) , 
production sub-classes are 
scheduled FIFO (one job per sub- 
class), and serial jobs are 
scheduled in priority sequence. 

If resources are not available 
to schedule a parallel or 
production job, no further 
lower class or sub-class jobs 
will be scheduled until re- 
sources become available. 

If for some reason the active 
job in a sub-class is blocked, 
the rest of the jobs are not 
scheduled. If a serial job is 
not scheduled because of lack of 
resources, the lower priority 
serial jobs are looked at for 
scheduling purposes. 

Class and sub-class priorities . 
are specified at system genera- 
tion time and may be modified 
only at system start-up time. 



XMS 

Up to 3*2 job classes with up 
to 15 priorities in each class 
may be defined. Jobs are 
scheduled within each class in 
priority sequence. If the highest 
priority job within a class cannot 
be scheduled, the next highest 
priority job may be scheduled. 

The class specification may be 
dynamically changed by the operator 
Via key-in, the operator may 
change the priority and the 
attributes of the jobs under any 
class. 

Generally, XMS job scheduling is 
more flexible. 
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FUN CTIONAL CHARACTERISTICS 

I Multi-Programming (Continued) 

xos 

(b). CPU Dispatching 

Available CPU time is allocated 
to classes and sub-classes in 
the priority sequence defined 
at system generation. When a 
job is in wait state, CPU time 
is then allocated to the next 
priority job. This scheme 
■ v optimizes turnaround of the 
' highest priority job and is 
preferred by BDP users. Control 
must be exercised, however, to 
prevent placing compute-bound 
jobs in the highest class where 
" they can severely degrade turn- 
around of lower-priority 1/0- 
bound jobs. 



XMS 

CPU time is allocated to classes 
by the quantum rotational method. 
Turnaround time of all jobs is 
approximately proportional to 
their execution time. This scheme 
is not acceptable to BDP users 
who want maximum turnaround for 
the highest priority jobs. 
According to Programming Develop- 
ment, the existing queuing and 
quantum structure can be easily 
modified to (optionally) optimize 
the turnaround of highest priority 
jobs. 



(c) Resource Allocation 

Although slight differences exist, both systems were judged 
equivalent in Resource Allocation. Both require that maximum 
resources for the entire job be available before a job may be 
scheduled. Both allow jobs to be started with less than the 
total required resources with a finite chance of "deadlock." 



XOS 

(d) Memory Management 

Batch jobs, once in core, are 
not swapped out even in long 
wait situations such as resource 
blockage or volume mounting/dis- 
mounting. 



XMS 

XMS memory management is superior 

in that long wait times are reduced 
by the swapping mechanism. Time 

quantum needs to be adjusted to 
avoid swapping during short I/O 
times (e.g., disk seek). 
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FUNCTIONAL CHARACTERISTICS 

I Mul ti-Programming (Continued) 

XOS 
(e) Conditional Execution 

Job predicate relationships are 
determined by the physical order 
of appearance in the job stream. 
Conditional execution is im- 
plemented via the Job Switch 
Word. 



XMS 

Predicate job scheduling and 
job step forking are accomplished 
through SCHEDULE' and^BATChV 
commands. Conditional execution 
may be controlled by command 
language and logical expressions, 
a more flexible arrangement. 



(f) Peripheral Utilization 

System resources are released 
at job end. 



Although roughly equivalent to 
XOS (see Resource Allocation) , 
the xFREE) command enables users 
to release peripherals before 
job end if appropriate. Dynamic 
reassignment of system resources 
to privileged job classes also 
contribute to better peripheral 
utilization. - 



(g) Sharable In-Core Libraries 

Not sharable, separate copies 
required. 



User library routines and language 
processors (except COBOL) are 
sharable. 



II File Management 



XOS 



XMS 



(a) Cataloging 

The catalog structure, automatic updating of geneological catalogs, 
and non-automatic updating capabilities of XOS and XMS are approxi- 
mately equivalent , however, XMS allows job-end independent cataloging. 
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FUNCTIONAL CHARACTERISTICS 
II Fil e Management 

XOS 
(b) File Generation 



XMS 



The file generation, version facilities and ability to reference 
files are similar in XOS and XMS. 



(c) Indexed Sequential Access Method (ISAM) 
The ISAM file creation, update, 
access and index scheme are the 
same as IBM . There is only one 
key entry plus pointer in the 
index per data block resulting 
in smaller space utilization for 
indices. This indexing scheme 
enhances sequential access 
activity. 



The XDS keyed random file is 
functionally equivalent to XOS 
ISAM. There is one key entry 
plus a 14 byte pointer per data 
record, resulting in a larger 
space utilization for indices. 
This indexing scheme enhances 
highly random access activity. 



(d) Multi-Volume Disk Files 

May be mounted sequentially 
(one at a time) or in parallel 
(all at the same time) . 



Must be mounted in parallel y 
(all at the same time) even 
if processed sequentially. 



(e) Tape Label Formats 

Supports the ANS and IBM tape 
label formats. 



Supports the ANS , IBM and 3PM / 
UTS tape label formats. 



(f) File Concatenation 

(The ability to link several files to form a super file) 
Only tape files with the same Both tape and disk files may be 
physical characteristics may be concatenated and may be catalogued 
concatenated. as a file group in a sub-file 

catalog. 



c 



;*. 1 n / 






B-12 



FUNCTIONAL CHARACTERISTICS 
II File Management (Continued) 

XOS XMS 

(g) Partitioned Files (Useful for transaction processing) 
Access to partitioned files None 
provided . 

(h) Locate Mode 

.(Locate mode allows faster I/O processing) I 

Available for tape and disk Available for tape files only, 
files. 

(i) Internal Secondary Storage Address 

Information on file space alloca- File space allocation uses real 
tion is maintained in a system addresses by chaining portions of" 
separated directory. This gives a file together through the actual 
each file a" virtual file space contents of a file, 
independent of real file space, 
- providing better device independence, 
reliability and modularity. " 

(j) Variable Block Le n gths 

User specified for tape or User specified for tape only. 
disk . 

(k) Record Contention Resolution 

This facility, a requisite for transaction processing, is provided 
by neither system. Contention is resolved at the file level. 

Ill Communications Management 

This subject took more of our time than any other. There are basic 
differences between the XOS and XMS (UTS) • communications services 
which tended confuse the analysis of their functional capabilities. 
This section will firstly compare the functional capabilities, and 
then contrast the differences between the two implementations. In 
some cases, these differences have no effect on functional capabilities. 
The services described for XMS presently exist in UTS. 
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FUNCTIONAL CHARACTERISTICS 
III Communications Management (Continued) 

XOS 
(a) Bi-point 



XMS (UTS) 



XOS (TAM) and XMS (UTS) are equivalent in their ability to 
allow a single terminal and a single program to communicate 
with each other. 



( 



(b) Multi-Drop (Polling) 
__ Support for polled terminals 
is available under TAM. 



Programming Development estimated 
6 man-months to support polled 
terminals on multi-drop lines. 



(c) Queuing 

(QTAM provides the ability to queue messages from a communication 
network in core or disk, process these messages under program- 
control and return the messages to a queue, then output these 
messages from the queue to the communication network with the same 
or different destinations.) 



A QTAM capability is planned 
for XOS. 



XMS (UTS) allox^s a message to be 
received from a terminal, processed 
and placed in a file (on disk) 
associated with another terminal. 
The program associated with the 
other terminal can retrieve the 
message from the file and output it 
to the destination terminal. Since 
XMS processors are sharable, the tw 
programs described above could 
actually be the same piece of 
code. Many terminals, constituting 
a network, can be handled in this 
fashion. The functional equi- 
valence of QTAM is, therefore, 

inherent in UTS . \ 

1 
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FUNCTIONAL CHARACTERISTICS 
III Communications Management (Continued) 

XOS 
■ (d) Automatic Log-On 

Terminals are "logged" into 
the system and checked/validated 
at the time the service program 
is invoked at the computer 
center. 



XMS (UTS) 

XMS (UTS) provides the ability 
to automatically associate a 
specific service program with 
a specific terminal at the time 
the terminal logs-on. An enhance- 
ment is planned to recognize a 
terminal by line or poll location. 



(e) Multi Terminal Programs 
Available via TAM. 



The ability of a single (sharable) 
processor to handle multiple 
terminals is inherent in UTS (See 
paragraph (c) above.) 



(f) Dial Out 

Not available in either system. Will require an estimated 6 man- 
months to implement. 

(g) Network Definition 

TAM provides the. ability to UTS recognizes the presence of 

define a network which identifies terminals, hence a network, at 

lines and terminals on those log-on time. The network is 

lines, and their polling sequences, implied and re-defined automatical! 

Changes to the network and polling as terminals log-on and sign-off. 

lists are controlled centrally This capability is inherent to 

by program or operator control. UTS . 



(h) Similarity to IBM Approach 

Since XOS TAM is similar to IBM 
BTAM, it represents a selling 
advantage. 



The UTS service is different 
from IBM and represents a 
marketing difficulty. 
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FUNCTIONAL CHARACTERISTICS 
III Comm unications Management: (Continued) 

XOS 



XMS 



(h) D ifferences in Implementation . (These differences do not imply a 
functional advantage or disadvantage unless specifically stated.) 



XOS 
(i) Each terminal is dedicated 
to a specific libraried 
program called from the 
central site, although that 
program can call several 
associated sub-systems. 



XMS (UTS) 
(i) Any terminal (or device) 
can call and run any 
libraried program and its 
sub -system from a remote 
location. 



(ii) Buffers are in user area 
(fixed) 

-Additional user concern 
-Potentially use more core 



(ii) Buffers are in system area 
(dynamic) 
-No user concern 
-Potentially save core space 



(iii) User's program continually (iii) User's program swapped out 



resident even if no terminal 

activity. 

-Multiple on-line applica- 
tions require more core 
space. 

-No significant difference 
from UTS for single applica- 
tion with high terminal 
activity. 



if no terminal activity. • 

-Multiple on-line applica- 
tions swapped into same 
core space. 



(iv) Terminal- to- terminal com- (iv) COMSYS in development for" 
munications needs processor UTS will provide terminal- 
similar to UTS COMSYS. to-terminal communications, 



C 
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FUNCTIONAL CHARACTERI S TI CS 

III Communications Management (Continued) 

xos 

(v) Use File Management System 
files with OPEN/CLOSE 
activated only at start/ 
end of" job 
-Record contention is 

resolved within user's 

program. 



XMS (UTS) 
(v) File OPEN/CLOSE overhead 
is high, but is being 
avoided for UTS "internal 
communication" by using 
symbiont files. 
-Symbiont files not com- 
patible with user files. 
J -Record contention resolution 
by File Management would 
eliminate this problem. 



IV Time- Sharing 

XOS 
(a) Availability 

Confidential CII plans are to 
implement time- sharing under 
XOS with a target date of 
Oct. 71 (XDS release no sooner 
than 1Q72) . 



XMS 



Exists in UTS, 



(b) Compatibility 

If implemented by CII, the 
system would likely be in- 
compatible with BTM or UTS. 



Compatible with UTS 



(c) Difficulty of Implementation 
Programming have estimated 
that it would take XDS at least 
9 man-years to produce a BTM- 
like system. (BTM has taken 
14 man-years to date.) 



Exists in UTS. 
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FUNCTIONAL CHARACTERISTICS 
IV Time-Sharing (Continued) 

XOS 



XMS 



(d) Service Level (Number of terminals, response, etc.) 
Unknown, but estimated to be Like UTS. 
-si-mdttar-to BTM. 

V Real-Time 

Not available in first release of either system. We estimated that 
expected functions and service levels would be similar. 



VI Symbionts 



XOS 



Media "conversion service programs j 
functionally equivalent to extended 
symbionts^ are filed and scheduled 
as user jobs. 



XMS 
Extended symbionts are system 
services and are more convenient 
to use. v 



VII System Management 

(a) Number of Operator Consoles 

1 

(b) Dynamic System Tuning 



XMS (UTS) appears more complete, 



(c) Crash Recovery 

Not enough information is available to draw a meaningful comparison. 
Both systems, however, have a demonstrated recovery capability. 



(d) Checkpoint /Res tart 

None in the first release, but 
a capability is planned 
(Specifications are unknown). 



Program initiated checkpoint/ 
restart capability will be 
provided in first release. 



(e) On-line Diagnostics 
None 



Available (UTS) 
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FUNCTIONAL CHARACTERISTICS 



VIII Job Control 



XOS 



(a) JCL Edit 

Equivalent in XOS and XMS. 



XMS 



(b) Catalog Procedures 

A catalog procedure cannot 
reference another catalog 
procedure (one level) 



A catalog procedure can reference 
multiple catalog procedures 
(multi-level) 



IX Processors 

A separate set of FORTRAN, COBOL, 
Meta-Symbol, Sort, etc. processors 
would have to be maintained for 
XOS. 



Use same processors as UTS/BPM. * 
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4. HARDWARE CONSIDERATIONS 



Core Residence 



XOS 

XOS can reside in as 
little as 14K words, 
but performance is 
noticably slow. We 
estimated that a 22K 
residence area' would 
assure acceptable 
throughput for a typical 
configuration. 



XMS 

XMS (no time-sharing) will 
require a 20K minimum resi- 
dence area, and 28K for a 
typical configuration with 
acceptable performance. 
(6K larger than XOS) 



Time-Sharing 



Estimate additional 4K Additional 4K residence, 
residence. 



7240 Support 



Require XDS effort to 
support under XOS. 



System Residence 



RAD or Disk 



RAD (Disk planned) 



•In summary, XOS with its smaller core residence requirements and disk 
residency offers a clear advantage for medium-scale batch systems such as 
the Sigma 6. Both systems offer larger core residence and RAD residence 
where these can be marketed as performance features on large-scale configura- 
tions such as Sigma 9. 









5 . EXPANDABILITY 



Time-Sharing 



XOS 



. Confidential CII plans are to 
implement time- sharing under XOS 
•with a target completion date of 
Oct. 71. (XDS release no sooner 
than 1Q72) If implemented by 
CII, the system would likely be 
incompatible with BTM or UTS. 

Programming have estimated that 
it would take XDS at least 9 man- 
years to produce BTM- like time- 
sharing under XOS. (BTM has 
taken 14 man-years to date) . 

The service level (no. of users, 
response) of XOS time- sharing 
and impact on batch throughput 
are unknown at this time, but 
are estimated to be similar to 
BTM. 
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XMS 



Exists in UTS. 



Sigma 9 Extended Memory (beyond 128K) 

Would require separate XDS 

effort. 



Utilize UTS changes planned 
for release 9/71. 



Sigma 9 Multi-Processor 
XDS may be able to utilize the 
design of the CII multi-processor 
operating system, SIRUS 8 (Q.A. 
6/71). However, there is enough 
difference between the Sigma 9 
and IRIS 80 that it may require 
a significant XDS effort. 



UTS multi-programming has not 
been designed. Although this 
may be difficult, XMS would 
utilize this effort. 
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EXPANDABILITY (Continued) 



XOS XMS 

Future Peripherals 

Would require separate effort if Utilize UTS support. 
CII did not support XDS devices 
or controllers (e.g., 7240). 
However, if XDS provided) support 
for new peripherals, it would 
enhance the sale of these devices 
to CII. 


Communications Management System 

The existing communications capabilities of XOS and XMS are discussed 

under Functional Characteristics. Both of these capabilities are 

considered equally small when viewed within the much larger context 

of a Communications Management System. It appears, however, that the 

inherent differences between XOS and XMS would result in a different 

implementation of CMS. A further study would be required to probe 

the functional differences, their desirability, salability, and 

difficulty of implementation. 
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6. CONVERSION 

Conversion is a significant consideration in most BDP user's decision to 
upgrade to a different computer system. 

In our analysis, we considered the difficulty of converting files, programs 
and job control language. Several schemes were tried and all gave roughly 
equivalent results. The following table provides an approximation of the 
difficulty of conversion using a BPM to XMS conversion factor of 1. 

to XMS to XOS 

from BPM 1 .6 

from IBM 6 3 



COMPANY PRIVATE 



COMPANY PRIVATE 



7. LOGISTICS 



XOS 



Translation 



Four levels of translation have been 
identified: 

(a) Reference and User's Manuals, 
required for Beta test sites 
and user release. These docu- 
ments require a high level of 
editing. 

(b) Internal Design Documents, 
required for XDS modifications, 
and Q.A. 

(c) Listing comments, required for 
XDS modifications. 

(d) Mnemonics (symbolic labels) , 
required for major XDS code 
changes, but may be computerized 
using a one-for-one replacement. 

The above levels of translation are 
required" at initial turnover, and 
continually as updates are released 
to XDS . 
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XMS 



None 



Admini s t r a tion 

The administrative problem includes 
coordination of XDS-CII working 
relations, translation of updates, 
and merging XDS^modifications with 
CII updates to create new releases. 
We anticipate a delay of 4 to 6 
months between CII release of XOS 
SIDIR's and updates and their release 
to the field by XDS. 



Because it is an in-house effort, 
the administration of XMS is 
greatly simplified. The lack 
of a 4 to 6 month time delay as 
in XOS means that XMS could 
mature more quickly after initial 
release. 



COMPANY PRIVATE 



CUiVlf ; Ai\n i-'i'ui/'Ali: 



LOGISTICS (Continued) , 

XOS XMS 

Maintenance 

The maintenance problem is complicated Large part is common with 
by language differences, and potential UTS. 
differences in CII and XDS objectives 
for XOS . 

Customer and Field Support 

Sales, Analyst and Customer training Large part is common with 

would have to' be duplicated for UTS. 

XOS and UTS. 

Libraries 

A duplicate set of program libraries Common with UTS. 

would have to be maintained for XOS 

as well as UTS. 

"'■■■ Other Project Impact 

XOS, in requiring a higher level 
of XDS resources, would have a 
.higher impact on other XDS projects 
than XMS. 
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